Distributed file systems offer many compelling advantages in establishing high performance computing environments. One example is the ability to easily expand, even at large scale. Another example is the ability to support multiple unique network protocols. In one example, a distributed file system can operate under a cluster of nodes topology, whereby clients can connect to any node among the cluster of nodes to perform file system activity. Individual nodes among the cluster of nodes each can contain their own processor(s), storage drives, memory and the like. Operating together in a cluster, the nodes can respond to client requests, store data, mirror data, and accomplish all the tasks of a modern file system. A cluster of nodes, in some cases, can provide easy scalability by providing for new nodes to be added to the cluster of nodes to increase the amount of storage space within the distributed file system and/or to meet other needs of the users of the distributed file system.
One demand that users of a distributed file system likely have is to avoid any single point of failure to user critical work flows. For example, if a storage device within one of the nodes fails, users expect the data to be useable from a secondary source, with as little disruption as possible. This is one reason why data is mirrored across more than one storage device and more than one node. If a drive or a node fails, a client can still find the data they seek within a different drive and/or connect to a different node. With businesses depending on the reliability of their data storage systems in order to serve their customers, many businesses expect a distributed file system to continue to operate every hour of every day throughout the year. However, when an administrator of a distributed file system operating within a cluster of nodes wishes to upgrade the file system to a new version, the process can cause disruptions to users of the file system. For example, if every node of the file system needed to be upgraded simultaneously, clients would be unable to connect to a node and access data stored within the file system during the upgrade process. By upgrading one node or a small subset of nodes at any one time, the remaining nodes not currently undergoing an upgrade can still service client requests. However, if nodes are upgraded piecemeal, nodes running two different versions of the operating software may be incompatible. Therefore, there exists a need for nodes running two different versions of the operating system during a rolling upgrade to remain compatible at least until the entirety of the nodes of the cluster are using the same version of the operating software.